In a software-defined network (SDN) architecture, the control plane that implements important network routing and switching functionalities and the data forwarding plane are decoupled. This feature differs from the traditional network management protocols, such as Simple Network Management Protocol (SNMP) and more recent Network Configuration Protocol (NETCONF). The control plane in SDN can be logically centralized and implemented with a variety of hardware components of varied architectures. As a result, the data plane in SDN may utilize inexpensive and simplified network switches or routers configurable by an SDN controller. The SDN paradigm has increasingly gained popularity in both research and commercial environments due to its scalability, cost-efficiency, reliability, and flexibility in customizing and optimizing network services to specific user needs.
In a typical SDN architecture, a logically centralized SDN controller is employed to control the behaviors of underlying data forwarding elements (e.g., switches and routers) through some southbound application programming interfaces (APIs). On the other hand, the SDN controller, either implemented in a centralized or distributed manner, also provides an abstraction of the network functions with a programmable interface, called northbound API, for application entities to consume the network services and configure the network dynamically.
Some SDN controllers, e.g., Floodlight, adopt Representational State Transfer (REST) architecture style for northbound APIs (or REST APIs), e.g., used for managing and configuring the SDN network. The Hypertext Transfer Protocol/1.1 (HTTP/1.1) is typically used to implement such an API following REST architectural style.
A REST interface is a communication technique deployed for clients and servers to interact with each other over the Internet. For example, a client initiates a request that is processed by the server and a response is returned from the server to the client. A REST request may includes resource identifiers and actions (such as GET, PUT, POST, and DELETE) to be taken on the resources,
To reduce web response latency, network traffic and server load, caches are commonly utilized to store copies of responses that include the requested representations. Then if there is a subsequent request for the same Uniform Resource identifier (URL) for example, the cached response can be retrieved and provided to a client, thereby avoiding requesting and/or accessing the original server for the same representation. Caches can be located at the server side or the client side, or between a server and a client (intermediary cache or proxy cache).
The performance and scalability of a RESTful architecture is largely determined by the effectiveness and efficiency of caches. The current HTTP/1.1 cache control scheme treats a resource representation (e.g., a document) as the smallest unit of caching and thus only allows a uniform cache control policy to be applied on the entire resource representation. However, in the real world, especially in the context of SDN northbound API, different parts or elements of a representation often change their state at different frequencies, as configured by the corresponding application program. If a representation is cached according to the most frequently changed parts, the less frequently changed parts can become unavailable too soon because the entire representation expires at the same time. If the representation is cached according to the least frequently updated parts, cache utilization is inefficient and stale content tends to occur. A middle ground control policy chosen between the two extremes can lead to both caches misses and stale content.